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V 

The  reuse  of  existing  software  components  can  significantly  improve 
productivity  on  software  development  projects.  A  generic  architecture 
provides  a  way  to  increase  the  level  of  reuse  beyond  that  possible  with 
traditional  approaches.^ 

f  — — — 

^Typically,  reusable  components  are  available  from  software  libraries 


that  provide  them  for  use  on  a  wide  variety  of  applications.  However, 
with  a  generic  architecture,  the  components  are  developed  for  use  in  the 
applications  of  a  specific  project  or  organization  and  are  designed  to 
meet  the  specific  requirements  of  those  applications.  This  change  in 
focus  makes  it  possible  to  take  advantage  of  similarities  in  the 
requirements  and  design  of  those  applications  so  as  to  develop  reusable 
components  for  operations  that  are  difficult  to  support  with  more  general 
purpose  library  components.^ 

.  In  general,  the  reuse  of  software  components  contributes  to  software 
productivity  by  reducing  the  number  of  lines  of  new  code  that  must  be 
designee,  coded,  tested,  and  maintained.  However,  the  benefits  to  be 
derived  from  a  generic  architecture  are  not  limited  to  greater  productiv¬ 
ity,  but  include  greater  reliability,  enhanced  interoperability,  improved 
operator  performance,  and  lower  training  costs  as  well.  Generic  archi¬ 
tectures  also  make  software  more  adaptable  to  changing  requirements, 
environments,  and  technology  and  provide  strong  support  for  the  rapid 
prototyping  of  related  applications. 

'  /'  fh  J 
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REUSABLE  COMPONENT  LIBRARIES 

The  reuse  of  software  components  is  common  in  most  projects.  It 
may  be  as  simple  as  the  exchange  of  source  code  among  programmers  who 
recognize  common  requirements  and  opportunities  for  code  reuse.  However, 
in  such  cases,  the  code  is  often  maintained  separately  in  each  applica¬ 
tion  in  which  it  is  used.  Although  some  time  is  saved  in  the  design  and 
coding  of  the  component,  the  other  benefits  of  common  testing  and 
maintenance  are  lost. 

A  more  organized  approach  is  to  place  reusable  components  in  a 
common  library.  Each  component  is  tested  and  documented  before  it  enters 
the  library.  Copies  of  the  code  and  documentation  are  distributed  to 
users  on  request.  Problems  with  a  component  are  reported  to  the  library 
where  they  can  be  fixed  and  the  changes  made  available  to  all  users. 

Reusable  component  libraries  typically  serve  a  number  of  projects 
in  an  effort  to  maximize  the  opportunities  for  the  reuse  of  the  compo¬ 
nents.  Libraries  also  collect  components  from  a  variety  of  sources  to 
increase  the  likelihood  that  they  will  have  the  components  needec  to  meet 
the  specific  requirements  of  their  client  projects.  At  some  point,  the 
number  of  components  may  become  large  enough  to  require  the  use  of  classi¬ 
fication  systems  and  retrieval  software  to  aid  in  the  identification  of 
the  most  appropriate  component  for  a  particular  use. 

The  typical  library  component  is  designed  to  perform  some  well 
defined  function  that  is  likely  to  be  required  in  a  number  of  different 
software  systems.  They  are  particularly  useful  when  they  encapsulate  the 
expertise  required  to  perform  a  complex  operation  that  would  be  difficult 
or  expensive  to  program.  Device  drivers,  window  managers,  and  complex 
mathematical  functions  are  good  examples.  They  can  include  major  subsys¬ 
tems  which  provide  a  significant  part  of  the  software  environment  in  which 
an  application  program  will  operate.  In  most  cases,  they  are  designed  to 
be  independent  of  the  design  of  the  application  in  which  they  are  used. 
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This  element  of  design  independence  is  illustrated  in  Figure  1. 

The  figure  provides  a  conceptual  model  of  three  applications,  of  very 
different  design,  which  share  several  reusable  components.  Letters  have 
been  assigned  to  the  components  for  identification.  A  different  set  of 
components  has  been  used  in  each  application  and  the  components  have  no 
direct  interfaces  with  each  other.  The  interface  code  that  invokes  the 
operations  of  each  of  the  reusable  components  is  generally  not  reusable 
and  is  developed  as  new  code  in  each  of  the  applications. 


Figure  1.  The  Reuse  of  Components  in  Applications 
with  Different  Designs 


Section  2 


GENERIC  ARCHITECTURES 

In  the  development  of  related  applications,  design  independence  is 
not  the  central  issue.  For  these  applications  it  is  often  possible  to 
use  a  common  high-level  design  and  to  develop  additional  reusable 
components  that  are  based  on  that  design.  The  common  design  and  design- 
dependent  reusable  components  are  the  essential  elements  of  a  generic 
architecture. 

The  use  of  a  generic  architecture  is  illustrated  in  Figure  2.  Here 
the  high-level  design  of  the  two  applications  is  the  same.  Nominally,  each 
application  has  a  similar  set  of  components,  and  those  components  have 
direct  interfaces  with  each  other.  Many  of  the  components  can  be  reused 
without  change.  Differences  in  the  requirements  of  the  two  applications 
are  handled  by  modifying  or  replacing  only  those  components  affected  by 
those  requirements.  In  Figure  2,  components  "C"  and  "E"  are  different  i r 
the  two  systems,  but  they  have  the  same  interface  with  the  other 
components  in  both  systems.  This  illustrates  the  generic  architecture 
approach  to  reusable  software. 


Figure  2.  The  Reuse  of  Components  in  Systems  with  a  Common  Design 
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A  generic  architecture  provides  a  high-level  design  for  a  family  of 
related  applications  and  a  set  of  reusable  components  that  are  intended 
for  use  in  those  applications.  The  use  of  a  common  high-level  design 
allows  code  that  is  dependent  on  that  design  to  be  included  in  the 
reusable  components.  A  good  example  of  design-dependent  code  is  code 
that  is  contained  in  one  component  and  invokes  a  function  contained  in 
another  component.  Such  a  design  dependency  limits  the  use  of  the  first 
component  to  designs  in  which  the  second  component  is  also  used.  Accep¬ 
tance  of  design  dependencies  allows  more  of  the  code  of  the  application 
to  be  included  in  the  reusable  components.  However,  the  use  of  those 
components  is  limited  to  applications  in  which  the  components  have  the 
same  design  relationship. 

Under  what  circumstances  will  the  designs  used  in  a  family  of 
applications  be  similar  enough  to  allow  the  use  of  a  generic  architecture? 
The  answer  to  this  question  often  depends  more  on  the  operating  context  or 
environment  of  a  set  of  applications  than  on  the  applications  themselves. 

For  example,  applications  that  are  executed  on  networked  work¬ 
stations,  such  as  those  shown  in  Figure  3,  are  likely  to  be  good  candi¬ 
dates  for  the  use  of  a  generic  architecture.  This  is  because  those 
applications  are  likely  to  have  a  large  number  of  common  support  require¬ 
ments.  These  might  include  support  for  an  interactive  dialog  with  the 
user,  the  ability  to  print  reports,  or  the  ability  to  send  and  receive 
messages  using  standard  protocols.  Although  the  displays,  reports,  and 
messages  will  be  different  for  each  application,  much  of  the  supporting 
code  required  to  produce  displays,  print  reports,  or  format  messages  may 
be  the  same.  Moreover,  the  basic  control  mechanisms  are  likely  to  be 
similar  in  most  of  the  applications. 

It  is  usually  not  difficult,  in  such  situations,  to  place  the  code 
that  is  truly  application  specific  in  components  that  are  separate  from 
those  supporting  the  more  generic  elements  of  an  operation.  This  allows 
the  application  specific  components  to  be  replaced  or  modified  without 
changing  the  remaining  supporting  components. 
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Figure  3.  A  Workstation  Network  Applications  Environment 

The  amount  of  code  that  can  be  reused  in  similar  applications  can 
be  surprisingly  large.  Magnavox  was  able  to  reuse  75%  of  the  code 
developed  for  the  Army's  Advanced  Field  Artillery  Tactical  Data  System 
(AFATDS)  on  another  project,  the  Elevated  Target  Acquisition  System. 
SofTech  was  able  to  reuse  68%  of  the  code  developed  for  the  applications 
of  the  Air  Force  Rapid  Emergency  Reconstitution  (RAPIER)  project  across 
the  nine  applications  of  that  project.  It  has  been  estimated  that  over 
70%  of  the  code  developed  for  Apple  Macintosh  applications  could  be 
reused  across  those  applications. 

The  recent  trend  toward  the  procurement  of  large  numbers  of  commer¬ 
cial  desk-top  computers  and  workstations  for  general  use  throughout  a 
command  or  program  has  created  ideal  conditions  for  the  development  and 
use  of  generic  architectures  and  for  the  use  of  reusable  software  in 
general.  Within  such  an  environment,  there  are  likely  to  be  numerous 
opportunities  to  exploit  similarities  among  related  applications. 


5 


Section  3 


RELATIONSHIP  TO  LIBRARIES  OF  REUSABLE  COMPONENTS 

The  development  of  a  generic  architecture  is  not  an  alternative  to 
the  use  of  a  library  of  software  components  in  the  development  of 
computer  software.  Instead,  it  compliments  the  use  of  library  components 
by  allowing  additional  components  of  an  application  to  become  reusable. 
The  development  of  a  generic  architecture  should  take  full  advantage  of 
any  components  that  can  be  supplied  from  an  existing  library. 

The  important  difference  between  the  components  that  might  be 
supplied  by  a  library  and  the  additional  components  that  would  be 
developed  for  a  generic  architecture  is  that  library  components  usually 
stand  alone.  They  do  not  normally  depend  on  operations  performed  by 
other  library  components  although  they  may  require  the  services  of  the 
underlying  operating  system. 

The  additional  components  developed  for  a  generic  architecture 
generally  do  not  stand  alone.  They  must  operate  in  the  same  design 
context  and  in  conjunction  with  other  components  on  which  they  depend  for 
support.  They  can  be  reused  across  applications  only  to  the  degree  that 
those  applications  share  a  common  design. 

Any  stand-alone  components  that  might  be  developed  for  a  generic 
architecture  are  good  candidates  for  inclusion  in  a  reusable  component 
library.  The  remaining  design-dependent  components  might  also  be 
included,  but  they  raise  a  number  of  special  problems.  The  interdepen¬ 
dencies  among  these  components  must  be  clearly  identified  for  the  users 
of  the  library  so  that  all  of  the  necessary  components  are  included  in 
any  application  in  which  they  are  used.  It  is  also  useful  for  a  library 
to  provide  some  way  to  identify  all  of  the  components  that  are  used  in  a 
given  generic  architecture  so  that  they  can  be  examined  as  a  group  for 
possible  use  in  other  applications. 

Indeed,  other  projects  which  have  the  same  operating  environment 
may  be  able  to  reuse  a  generic  architecture.  If  not,  they  may  be  able  to 
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adapt  large  parts  of  it  to  a  new  generic  architecture.  Existing  generic 
architectures  can  also  serve  as  useful  examples  to  later  developers.  Thn 
latter  consideration  alone  probably  justifies  their  inclusion  in 
libraries  of  reusable  components. 

It  may  also  be  desirable  to  include  a  generic  architecture  in  a 
library  for  long  term  maintenance,  particularly  if  it  is  likely  to  be 
reused,  in  whole  or  in  part,  by  other  projects. 

However,  in  most  cases,  the  organization  that  operates  a  library  is 
probably  not  the  ideal  organization  to  develop  a  generic  architecture. 

The  development  of  a  generic  architecture  requires  a  fundamentally  differ¬ 
ent  point  of  view.  The  ability  to  achieve  high  levels  of  software  reuse 
within  the  applications  based  on  a  generic  architecture  depends  to  some 
degree  on  resisting  the  temptation  to  over-generalize,  i.e.,  to  design 
the  components  to  meet  requirements  that  go  beyond  those  of  the  project 
that  plans  to  use  the  architecture.  By  its  nature,  a  library  organiza¬ 
tion  tries  to  make  components  useful  to  a  wide  range  of  users  and  is 
probably  more  likely  to  over-generalize  than  a  project  organization. 

A  generic  architecture  is  inherently  project  specific.  Ideally, 
its  development  should  be  sponsored  by  the  organization  responsible  for 
the  project  that  will  be  supported  by  the  architecture.  No  one  else  has 
adequate  information  on  the  requirements  of  the  applications.  No  one 
else  is  as  likely  to  benefit  from  its  development. 
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Section  4 


ADA  SUPPORT  FOR  GENERIC  ARCHITECTURES 


The  ability  to  develop  an  inventory  of  reusable  "software  parts" 
was  a  major  consideration  in  the  design  of  the  Ada  language.  It  should 
not  be  surprising  that  Ada  provides  strong  support  for  generic  architec¬ 
tures  and  for  reusable  components  in  general. 

Reusable  components  should  be  treated  as  "black  boxes"  which  perform 
well  defined  operations,  but  keep  the  details  of  the  implementation  of 
those  operations  hidden  from  the  user.  The  object  here  is  not  secrecy, 
but  rather  the  ability  to  use  a  component  without  having  to  be  concerned 
about  the  details  of  its  implementation.  If  this  is  not  the  case,  it  can 
be  expected  that  the  user  will  soon  modify  the  component  and  it  will  no 
longer  be  reusable.  A  component  is  truly  reusable  only  when  it  can  be 
used  again  without  changing  the  program  code  of  the  component. 

4.1  Ada  Packages  As  Reusable  Components 

The  Ada  language  is  well  suited  to  the  development  of  black  box 
components.  Most  of  the  operations  in  an  Ada  program  are  grouped  into 
"packages"  along  with  the  data  used  in  those  operations.  A  reusable 
component  in  Ada  is  usually  implemented  as  an  Ada  package. 

The  interface  to  an  Ada  package  is  defined  in  an  Ada  coded  package 
"specification".  That  interface  defines  the  form  of  all  program  calls  to 
the  operations  of  the  package  as  well  as  any  data  that  may  be  accessed 
from  outside  the  package. 

The  code  that  implements  the  operations  of  a  package  is  contained 
elsewhere  in  a  package  "body*1.  Here  one  would  find  the  code  that  carries 
out  the  operations  defined  in  the  interface  specification  as  well  as  any 
local  data  that  is  used  within  the  package. 
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4.2  Non-Intrusive  Modifications  To  Reusable  Components 


Ada  also  has  several  features  which  allow  the  programmer  to  modify 
the  operations  of  a  package  without  changing  the  program  code  of  the 
package.  The  two  most  important  are  "generics"  and  "separate  subunits". 

A  generic  package  differs  from  a  normal  package  in  that  it  allows 
selected  data  and  operations  in  the  package  to  be  redefined  at  the  time 
that  the  package  is  used  in  a  program.  The  package  specification  identi¬ 
fies  the  data  and  operations  that  can  be  changed  in  this  manner.  The 
remainder  of  the  package  is  unchanged,  and  no  permanent  changes  are  made 
to  the  program  code  of  the  package. 

A  separate  subunit  is  the  implementation  of  an  operation  outside  of 
the  package  in  which  it  is  defined.  Its  interface  is  still  defined  in 
the  package  specification,  but  its  program  code  is  separate  from  the 
package  body.  In  its  place,  the  body  contains  a  statement  that  indicates 
that  the  code  for  the  operation  is  contained  in  a  separate  subunit.  This 
means  that  the  program  code  for  that  operation  can  be  replaced  without 
changing  tne  code  of  the  package  body. 

Of  course,  it  is  always  possible  to  replace  a  component  that  cannot 
be  suitably  modified.  Indeed,  most  of  the  code  for  the  replacement  compo¬ 
nent  may  be  taken  from  the  original.  The  penalty  is  that  the  component 
is  now  unique  to  the  application  in  which  it  is  used  and  must  be 
maintained  separately  as  long  as  it  is  used. 

4.3  Object-Oriented  Development 

Ada  is  considered  by  most  authorities  to  be  an  "object-oriented" 
language.  This  means  that  it  allows  programmers  to  implement  software 
components  using  an  object-oriented  programming  style.  An  object- 
oriented  software  component  contains  all  of  the  data  used  to  represent 
some  real-world  object  an  well  as  the  code  for  all  operations  on  that 
object. 

For  example,  a  message  might  be  such  an  object.  An  object-oriented 
message  component  or  package  would  contain  all  of  the  data  required  to 
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describe  one  or  more  messages.  It  would  also  include  the  program  code 
for  all  of  the  operations  that  might  be  performed  on  messages.  Examples 
are  operations  which  create,  send,  receive,  and  display  messages. 

Object-oriented  development  provides  a  logical  basis  for  grouping 
operations  and  data  into  components.  In  the  process  it  reduces  the 
amount  of  data  that  needs  to  be  accessed  from  other  components.  This  can 
substantially  reduce  the  complexity  of  software  systems.  It  also  simpli¬ 
fies  the  interfaces  among  components  and  makes  them  inherently  more 
reusable. 

It  is  sometimes  argued  that  Ada  is  not  truly  an  object-oriented 
language  because  it  does  not  support  "inheritance".  Inheritance  in  an 
object-oriented  programming  language  allows  a  new  component  to  "inherit1’ 
all  of  the  data  and  operations  of  some  existing  component.  The  new 
component  may  contain  additional  data  and  operations  for  the  object  of 
the  original  component,  ho  changes  are  made  to  the  original  component 
and  no  special  provisions  need  be  made  in  advance  to  allow  its  code  to  be 
inherited  by  a  later  component.  In  effect,  this  allows  extensions  to  a 
reusable  component  without  changing  the  part  that  is  being  reused  in 
other  programs. 

This  would  be  a  convenient  way  to  modify  reusable  components  in  a 
generic  architecture.  However,  most  of  the  effect  of  inheritance  can  be 
achieved  through  the  use  of  generics  and  separate  subunits. 
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Section  5 


BENEFITS 

The  use  of  a  generic  architecture  has  a  number  of  important 
benefits. 

The  most  apparent  is  the  potential  for  a  significant  reduction  in 
both  the  time  and  effort  required  to  develop  and  maintain  the  applications 
which  use  the  architecture.  The  use  of  the  established,  tested  design  of 
the  architecture  can  streamline  the  design  phase  in  the  development  of 
later  applications.  For  each  application,  there  is  less  new  code  to  be 
developed  and  less  application-unique  code  to  be  maintained.  The  relia¬ 
bility  of  each  application  is  enhanced  through  greater  reliance  on 
components  that  have  been  used  and  tested  in  other  applications.  The 
availability  of  an  existing  design  and  components  should  also  reduce  the 
time  required  to  develop  applications  based  on  the  architecture. 

However,  the  benefits  to  be  derived  from  the  use  of  a  generic  archi¬ 
tecture  are  not  limited  to  streamlined  development  and  lower  maintenance 
costs. 

In  the  workstation  network  example  discussed  earlier,  the  use  of 
the  same  components  to  implement  message  protocols  and  other  standards 
assures  a  degree  of  interoperability  among  the  applications  that  would  be 
difficult  to  achieve  among  independently  aeveloped  applications. 

The  use  of  common  support  routines  in  the  interactive  user  inter¬ 
face  will  produce  a  common  "look  and  feel"  to  that  interface  across 
applications.  This  can  reduce  training  costs  and  contribute  to  improved 
operator  performance.  It  can  also  produce  a  degree  of  consistency  in  the 
man-machine  interface  that  makes  it  easier  to  reassign  operators  to  other 
applications  which  share  the  same  generic  architecture. 

The  need  to  confine  application-dependent  code  to  a  limited  number 
of  components  tends  to  make  applications  based  on  a  generic  architecture 
more  adaptable  to  requirements  which  may  change  from  user  to  user.  For 
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example,  changes  required  to  adapt  a  system  to  different  organizations 
are  likely  to  be  confined  to  those  application-dependent  components. 

Hardware  and  operating  system  dependencies  tend  to  be  concentrated 
in  the  reusable  components  of  a  generic  architecture.  This  can  be  an 
important  advantage  when  the  applications  are  moved  to  a  new  hardware  or 
software  environment.  In  most  cases,  modification  of  the  reusable 
components  containing  the  hardware  dependencies  can  be  done  once  for  all 
of  the  applications  using  those  components.  Without  a  generic  architec¬ 
ture,  it  is  more  likely  that  changes  would  have  to  be  made  to  a  larger 
number  of  application-unique  components. 

The  rapid  prototyping  of  new  applications  is  easier  if  there  is  an 
available  generic  architecture  for  similar  applications.  The  design  and 
supporting  code  are  already  integrated,  tested,  and  in  place.  Only  the 
application-specific  elements  of  the  prototype  need  be  added.  The  conven¬ 
ience  of  such  a  prototyping  "platform"  makes  it  easier  to  experiment  with 
different  versions  of  the  prototype  as  the  requirements  for  an  applica¬ 
tion  are  refined. 

Finally,  the  components  of  a  generic  architecture  are  designed  to 
be  adaptable  in  order  to  meet  the  requirements  of  the  different  applica¬ 
tions  that  will  use  the  architecture.  This  characteristic  also  makes 
them  more  adaptaole  to  future  changes  in  requirements  or  technology. 
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Section  6 


DEVELOPMENT  OF  A  GENERIC  ARCHITECTURE 

With  some  small  changes  in  emphasis,  the  development  of  a  generic 
architecture  and  its  applications  conforms  well  to  the  development  procesr 
defined  by  DOD-STD-2167A.  The  applications  covered  by  the  generic  archi¬ 
tecture  might  be  identified  as  separate  Computer  Program  Configuration 
Items  (CSCIs)  in  the  System/Segment  Specification.  The  generic  architec¬ 
ture  itself  would  constitute  an  additional  CSCI. 

The  use  of  a  generic  architecture  forces  the  software  developer  to 
give  more  attention  to  requirements  analysis  and  design  than  with  less 
coordinated  approaches  to  software  development.  The  level  of  software 
reuse  obtained  from  a  generic  architecture  is  highly  dependent  on  the 
amount  of  time  and  effort  given  to  these  critical  early  phases  of  the 
development  effort. 

6.1  Requirements  Analysis 

A  thorough  analysis  of  the  requirements  of  a  family  of  applications 
will  increas*--  the  likelihood  that  those  requirements  will  be  met  with 
reusable  components  rather  than  with  application-specific  code.  Draft 
versions  of  the  Software  Requirements  Specifications  (SRSs)  should  be 
completed  for  each  of  the  applications  prior  to  the  development  of  an  SRS 
for  the  generic  architecture.  The  application  SRSs  can  then  be  analyzed 
to  identify  the  common  requirements  that  should  be  included  in  the  SRS 
tor  the  generic  architecture. 

This  selection  of  the  requirements  for  the  generic  architecture  may 
be  more  complex  than  it  might  appear.  Few  of  the  requirements  are  likely 
to  be  stated  in  a  way  which  separates  the  unique  requirements  of  the 
individual  applications  from  the  more  generic  support  that  might  be 
implied  by  those  requirements.  The  SRS  for  the  architecture  must  define 
the  generic  support  requirements  that  are  often  hidden  beneath  the  surface 
of  the  specific  requirements  of  the  applications. 
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It  should  be  recognized  that  it  may  not  be  practical  to  define  a 
single  generic  architecture  for  all  of  the  applications.  Some  applica¬ 
tions  may  be  sufficiently  different  to  justify  a  separate  generic  archi¬ 
tecture  or  unique  enough  to  be  developed  independently. 

It  is  at  this  point  that  a  decision  should  be  made  on  the  feasibil¬ 
ity  of  a  generic  architecture  for  the  applications  under  consideration. 
That  decision  should  be  based  on  an  analysis  of  the  anticipated  benefits 
from  its  use  on  those  applications. 

6.2  Design 

The  design  activity  defines  the  components  of  each  CSCI,  the  inter¬ 
faces,  and  the  control  relationships  among  those  components.  The  results 
are  contained  in  Software  Design  Documents  (SDDs)  for  each  of  the  CSCIs. 

The  design  provided  by  the  generic  architecture  should  be  based  on 
an  analysis  of  the  requirements  of  each  application  that  separates  those 
that  might  be  met  with  reusable  components  from  those  which  are  unique  to 
the  application.  It  should  then  isolate  application-unique  functions  in 
a  limited  number  of  non-reusable  components  or  subunits  that  can  be 
replaced  from  one  application  to  the  next.  Requirements  for  functions 
that  operate  on  different  types  of  data  may  be  met  with  generic  compo¬ 
nents.  Components  of  the  generic  architecture  that  are  likely  to  be 
replaced  by  application-specific  components  should  be  designed  to  support 
the  later  integration  testing  of  the  architecture. 

The  design  process  is  likely  to  be  iterative  as  tentative  designs 
for  the  architecture  are  proposed  and  revised  in  response  to  the  reactions 
of  those  designing  the  dependent  applications. 

Although  the  design  of  the  generic  architecture  and  its  applica¬ 
tions  can  proceed  in  parallel,  the  design  of  the  architecture  should  be 
completed  first.  It  is  then  possible  to  describe  the  application  designs 
in  the  context  provided  by  the  design  of  the  generic  architecture.  The 
application  designs  should  cover  only  those  requirements  that  are  not 
covered  by  the  architecture  and  should  reference  the  design  of  the 
architecture  for  the  remainder. 
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6.3  Coding  And  Testing 


The  coding  and  most  of  the  testing  of  the  generic  architecture 
should  take  place  before  the  coding  and  testing  of  the  applications.  Th 
will  allow  the  architecture  to  be  used  to  support  the  testing  of  the 
applications  and  will  serve  as  an  effective  system  test  of  the  architec¬ 
ture  as  well. 
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Section  7 


ACQUISITION  CONSIDERATIONS 

To  this  point,  this  paper  has  focused  on  an  understanding  of  generic 
architectures  and  the  technical  issues  surrounding  the  use  of  a  generic 
architecture  on  a  project.  However,  there  are  other  issues  of  acquisition 
strategy  that  must  be  addressed  in  any  serious  attempt  to  implement  a 
generic  architecture. 

7.1  Project  Domain 

The  first  issue  is  the  domain,  in  project  terms,  of  the  architec¬ 
ture.  It  is  not  unusual  to  find  that  the  applications  of  several  differ¬ 
ent  projects  will  share  the  same  operating  environment.  There  may  even 
de  strong  requirements  for  the  interoperability  of  the  applications  on 
one  project  with  the  applications  of  the  others.  This  would  seem  to  be 
the  ideal  situation  for  the  use  of  a  single  generic  architecture  across 
all  of  the  projects. 

However,  there  may  be  a  number  of  problems  with  such  an  approach. 
Organizational  and  funding  responsibility  for  the  different  projects  may 
reside  in  distinctly  separate  organizations.  The  implementation  schedules 
for  the  projects  may  not  coincide.  Separate  acquisition  efforts  may  be 
planned  which  could  result  in  the  selection  of  different  contractors  for 
each  of  the  projects.  Finally,  it  may  be  that  no  single  organization  has 
the  background  necessary  to  assume  the  responsibility  for  the  development 
of  a  generic  architecture  that  would  be  used  by  all  of  the  projects. 

The  domain  of  a  generic  architecture  should  be  large  enough  to 
provide  adequate  opportunities  for  the  reuse  of  software  components  within 
the  domain.  As  long  as  that  requirement  is  met,  there  are  some  advantages 
to  limiting  the  domain  to  a  single,  well-defined  project.  For  example, 
the  schedule  for  that  project  would  not  be  affected  by  delays  experienced 
on  other  projects.  Control  would  remain  within  a  single  organization. 
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Issues  with  respect  to  the  requirements  or  design  would  not  have  to  be 
negotiated  among  projects  with  potentially  different  approaches  to  those 
matters. 

Such  a  strategy  could  still  be  of  benefit  to  other  projects.  The 
development  of  a  generic  architecture  for  one  project  would  provide  a 
prototype  or  model  for  the  subsequent  development  of  generic  architecture: 
on  other  projects.  Each  successive  architecture  would  be  a  refinement  o‘ 
the  design  and  components  used  in  earlier  architectures.  It  is  likely 
that  many  of  the  components  would  be  reused  in  any  event. 

7.2  Contractor  Selection 

Care  must  be  taken  to  structure  a  competitive  acquisition  so  that 
it  results  in  the  selection  of  a  contractor  with  the  commitment  and 
qualifications  necessary  to  successfully  implement  a  generic  architecture 
for  the  project.  Most  of  the  benefits  described  earlier  are  important  to 
the  government,  but  may  not  be  as  important  to  the  contractor  responsible 
for  the  initial  development  effort.  A  contractor  may  be  able  to  implement 
the  same  applications  at  a  competitive  price  without  a  generic  architec¬ 
ture  using  traditional  programming  practices  and  less  qualified  personnel. 
The  problems  with  such  an  approach  might  become  apparent  only  in  the 
longer  term  operation  and  maintenance  of  the  applications. 

The  key  technical  requirement  to  be  included  in  the  RFP  is  for  exten¬ 
sive  reuse  of  software  components  across  the  applications  of  the  project. 
The  contractor's  proposal  should  describe  how  the  reuse  of  software  will 
be  maximized.  Beyono  a  point,  greater  reuse  of  software  components  can 
only  be  achieved  through  the  use  of  a  common  high-level  design,  essentially 
the  generic  architecture  approach.  The  proposal  should  also  describe  the 
contractor's  past  experience  with  the  development  of  reusable  components 
and  provide  evidence  of  a  strong  commitment  to  software  reuse  within  the 
contractor's  organization. 
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7.3  Development 


The  results  achieved  through  the  use  of  a  generic  architecture  are 
directly  related  to  the  thoroughness  of  the  requirements  analysis  and 
design  activities.  Although  these  activities  are  critical  to  the  success 
of  any  software  effort,  they  are  particularly  important  when  defining  and 
developing  components  that  are  intended  for  reuse  across  different  appli¬ 
cations.  Typically,  additional  time  spent  in  requirements  analysis  and 
design  avoids  delays  in  the  subsequent  implementation  of  the  software. 

Unfortunately,  pressure  to  show  early  results  often  leads  to  less 
than  adequate  attention  to  these  critical  activities.  The  early  schedul¬ 
ing  of  requirements  and  design  reviews  leads  to  the  submission  of 
documents  that  are  often  incomplete  and  poorly  understood.  This  may  be 
followed  by  a  cursory  review  of  those  documents  that  does  not  uncover 
deficiencies  in  the  statement  of  the  requirements  and  conceptual  problems 
with  the  resulting  design.  Such  practices  will  certainly  reduce  the 
effectiveness  of  the  generic  architecture  as  a  source  of  reusable 
components  for  the  applications. 

Tne  schedule  for  the  requirements  analysis  and  design  activities 
should  be  based  on  industry  experience  with  projects  of  similar  size  and 
complexity.  Guidance  may  be  found  in  sources  such  as  Barry  Boehm's 
"Software  Engineering  Economics"  [1].  Additional  time  should  be  allowed 
for  the  editing  of  the  requirements  and  design  documents  to  meet  military 
standards  and  for  the  review  of  the  delivered  documents  by  the  program 
office. 

The  development  of  early  prototypes  of  the  architecture,  and  at 
least  some  of  the  applications,  may  absorb  much  of  the  pressure  to  show 
early  results.  The  prototypes  can  be  used  to  provide  the  users  with  a 
tentative  response  to  their  requirements.  As  such,  they  become  vehicles 
for  the  refinement  of  the  requirements  and  the  development  of  an 
appreciation  of  critical  design  issues. 


[1J  Barry  W.  Boehm,  Software  Engineering  Economics,  Prentice-Hall, 
Englewood  Cliffs,  N.J.,  1981. 
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Both  the  prototypes  and  the  resulting  requirements  documents  shoui" 
give  particular  attention  to  those  areas  which  experience  has  shown  have 
the  greatest  potential  for  the  types  of  reusable  components  provided  by  a 
generic  architecture.  These  include: 

•  The  interactive  interface  with  the  user, 

•  Reports  produced  by  the  applications, 

•  Data  base  requirements,  and 

•  Communications  standards  and  protocols. 

The  interactive  interface  should  be  specified  in  sufficient  detail 
to  completely  support  the  development  of  user  manuals  and  final  qualifies 
tion  tests.  Report  specifications  should  be  adequate  to  support  a 
aetailed  review  by  the  intended  users  of  the  applications.  The  data  base 
requirements  should  be  sufficiently  precise  and  detailed  to  allow  users 
to  verify  the  definitions  of  all  data  elements  and  the  logical  relation¬ 
ships  among  those  elements.  The  communications  standards  and  protocols 
should  address  in  detail  the  issues  of  interoperability  among  the 
applications  and  with  other  systems. 
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Section  8 


SUMMARY  AND  CONCLUSIONS 

The  reuse  of  software  components  improves  software  development 
productivity  by  reducing  the  amount  of  program  code  that  must  be  developed 
and  maintained  and  by  capturing  expertise  that  might  not  be  readily  avail¬ 
able  on  a  project.  The  generic  architecture  approach  to  reusable  software 
allows  a  significantly  greater  share  of  the  code  to  be  reused  in  applica¬ 
tions  which  can  share  a  common  high-level  design. 

Generic  architectures  compliment  the  use  of  libraries  of  reusable 
components  by  expanding  the  use  of  reusable  components  to  parts  of  an 
application  which  have  traditionally  been  considered  too  design  dependent 
for  reusable  software.  Most  of  the  components  available  from  libraries 
are  designed  to  stand  alone  while  those  developed  for  a  generic  architec¬ 
ture  often  require  the  services  of  other  components  developed  for  the 
architecture.  The  ability  to  achieve  high  levels  of  software  reuse 
depends  to  some  degree  on  limiting  the  scope  of  a  generic  architecture  to 
the  specific  applications  planned  for  that  architecture. 

The  Ada  language  is  well  suited  to  the  development  of  reusable 
components  and  generic  architectures.  Ada  packages  provide  a  well  defined 
interface  for  a  component  and  encapsulate  the  details  of  the  implementa¬ 
tion.  Generic  and  separate  subunit  features  of  the  language  allow  the 
operations  of  a  component  to  be  modified  without  changing  the  code  of  the 
component  itself.  The  language  supports  an  object-oriented  development 
process  which  provides  a  logical  and  efficient  basis  for  organizing 
operations  and  data  into  reusable  components. 

The  benefits  of  a  generic  architecture  include  a  significant  reduc¬ 
tion  in  software  development  and  maintenance  costs,  greater  reliability 
of  the  resulting  software,  improved  interoperability  among  applications 
based  on  the  same  architecture,  a  common  "look  and  feel"  to  the  interface 
of  those  applications,  and  greater  adaptability  to  changing  requirements, 
environments,  and  technology. 
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The  development  of  a  project-oriented  generic  architecture  and  its 
applications  fits  well  into  the  D0D-STD-2167A  defined  development 
process.  The  requirements  for  the  architecture  must  be  derived  from  the 
requirements  for  the  applications  supported  by  the  architecture.  The 
architecture  may  be  designed  in  parallel  with  its  applications,  but  its 
implementation  should  precede  that  of  the  applications  so  that  it  is 
available  to  supply  components  required  for  the  integration  and  testing 
of  the  applications. 

Several  issues  of  acquisition  strategy  need  to  be  addressed  in  the 
development  of  a  generic  architecture.  The  domain  of  the  architecture 
needs  to  be  broad  enough  to  provide  adequate  opportunities  for  the  reuse 
of  the  components  provided  by  the  architecture.  It  should  be  narrow 
enough  to  allow  it  to  be  successful  on  at  least  one  project.  The  contra:, 
tor  selection  process  should  be  structured  to  ensure  that  the  contractor 
is  sufficiently  qualified  and  committed  to  meet  the  software  reuse  goals 
of  the  project.  The  requirements  analysis  and  design  phases  of  the  work 
must  be  carefully  monitored  to  ensure  that  the  results  will  be  adequate 
to  support  the  successful  development  of  a  generic  architecture. 
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Section  9 


FURTHER  READING 


The  material  in  this  paper  is  based  on  a  study  done  by  SofTech  for 
the  U.S.  Army  CECOM  titled  "Generic  Architecture  Study"  dated  January  22, 
1988.  Copies  may  be  obtained  from  the  Center  for  Software  Engineering. 
Another  paper  based  on  the  study  and  titled  "The  Generic  Architecture 
Approach  to  Reusable  Software"  was  presented  at  the  Sixth  National 
Conference  on  Ada  Technology  and  is  contained  in  the  Proceedings,  pages 
390-394  (March  1988). 

An  excellent  introduction  to  the  use  of  Ada  in  object-oriented 
development  is  contained  in  an  article  by  Grady  Booch  titled  "Object- 
Oriented  Development"  that  was  published  in  the  February  1986  issue  of 
the  IEEE  Transactions  on  Software  Engineering  (volume  SE-12,  number  2, 
page  211) . 

An  account  of  the  use  of  this  approach  on  a  major  project  is  con¬ 
tained  in  the  "Phase  I  Final  Technical  Report  for  the  Mobile  Command  and 
Control  System  (MCCS)  Mission  Support  Segment  (MSS)"  that  was  prepared  by 
ScrTech  for  the  U.S.  Army  (CECOM)  and  the  U.S.  Air  Force  Space  Command/ 
SWSC,  dated  February  28,  1989.  It  is  also  available  at  the  CECOM  Center 
for  Software  Engineering. 
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